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Abstract 


Proper  requesting  and  tasking  of  airborne  Ground  Moving  Target  Indicator  (GMTI)  assets  to  satisfy 
specific  operational  needs  is  a  complex  problem  due  to  the  multi-dimensional  nature  of  GMTI  data 
collection.  A  high  level  of  technical  expertise  is  required  to  correctly  determine  GMTI  collection 
parameters  needed  to  satisfy  operational  mission  needs.  With  an  anticipated  higher  volume  of  GMTI 
collection  requests  than  can  be  accommodated  by  available  theater  ISR  assets,  some  form  of  prioritization 
and  assignment  of  requests  to  specific  assets  that  is  achievable  is  needed.  In  addition,  as  the  number  and 
types  of  GMTI-producing  ISR  assets  in  theater  increases,  the  challenge  is  to  understand  the  resource 
utilization  of  each  sensor  type  against  specific  mission  objectives  and  to  effectively  assign  collection 
requests  to  each  asset.  The  GMTI  community  would  benefit  from  tools  and  metrics  to  assist  non-experts 
in  requesting  and  tasking  GMTI  assets  in  a  manner  that  will  fulfill  their  mission  needs  and  quantify  GMTI 
collection  utility. 

We  present  a  new  Moving  Target  Indicator  Interpretability  Rating  Scale  (MTIIRS)  metric  for  measuring 
GMTI  data  quality,  and  a  suite  of  new  tools  for  both  requesting  GMTI  support  and  for  selecting  and 
tasking  GMTI  assets  to  achieve  desired  operational  objectives.  We  have  identified  mission  type,  target 
type,  and  area  of  interest  as  a  core  set  of  parameters  which  define  the  GMTI  collection  requirements  and 
give  rise  to  an  MTIIRS  level  (independent  of  a  specific  GMTI  asset).  Information  needs  are  derived  from 
a  set  of  mission  types,  such  as  high  value  target-tracking,  force  protection,  and  facility  monitoring.  Each 
mission  type  corresponds  to  a  predictive  model  used  to  compute  GMTI  collection  utility  for  a  given  target 
type,  area  of  interest  and  GMTI  sensor. 


1.  Introduction 

A  fundamental  challenge  of  Command  and  Control  (C2)  is  to  maintain  awareness  of  the  state  of  a  fluid 
and  dynamic  battlespace  environment.  This  is  accomplished  with  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  assets  that  are  tasked  to  collect  intelligence  information  and  monitor  the  dynamic 
state  of  the  battlespace  in  support  of  battlespace  missions  and  operations.  Such  assets  include  airborne 
platforms  equipped  with  video,  electro-optical,  infrared,  signals  detection,  radar,  and  other  sensing 
systems.  Managing  and  tasking  such  assets  to  collect  intelligence  information  in  a  manner  that  satisfies 
battlespace  operational  objectives  presents  a  C2  challenge  of  its  own  -  namely,  the  C2  of  ISR  assets. 

Effective  tasking  and  operation  of  ISR  assets  requires  understanding  which  platforms  are  best  suited  for 
which  intelligence  gathering  tasks  and  how  assets  should  be  operated  to  best  accomplish  the  tasks.  This 
problem  of  asset-task  pairing  is  a  complex,  multi-dimensional  problem  that  requires  models  and  metrics 
of  end-user  operational  needs  (e.g.,  required  data  fidelity),  models  of  sensor  systems,  and  predictive 
models  to  assess  the  utility  of  pairing  sensor  system  against  end-user  tasks.  Systems  based  on  such 
metrics  and  models  are  needed  to  streamline  the  process  of  formulating  requests  for  ISR  support  and 
planning  ISR  missions. 

Our  research  aims  to  construct  such  metrics,  models,  and  systems  with  a  specific  focus  on  airborne  GMTI 
(Ground  Moving  Target  Indicator)  platforms.  GMTI  platforms  employ  radar  and  other  sensing  systems 
to  detect  and  track  moving  targets  in  an  area  of  interest.  The  goal  of  a  GMTI  collection  may  be  to  simply 
categorize  typical  traffic  patterns  in  an  area  of  interest,  or  to  track  individual  vehicles  moving  in  an  area. 
GMTI  is  a  particularly  dynamic  type  of  intelligence  collection  that  presents  challenges  for  end-users  in 
need  of  GMTI  support  and  for  collection  managers  who  task  assets  to  provide  such  support.  In  this  paper, 
we  present  a  new  Moving  Target  Indicator  Interpretability  Rating  Scale  (MTIIRS)  metric  for  measuring 


required  GMTI  data  fidelity  (Section  2)  and  a  suite  of  new  tools  for  both  requesting  GMTI  support  and 
for  selecting  and  tasking  GMTI  assets  to  achieve  needed  operational  objectives  (Section  3).  We  also 
outline  future  directions  of  this  research  and  the  application  of  the  approach  to  other  sensing  modalities 
(Section  4). 

2.  Mission-Based  GMTI  Sensor  Planning 

2.1.  A  mission  model  approach  to  the  GMTI  sensor  planning  problem 

The  first  challenge  in  effectively  tasking  a  GMTI  asset  is  in  simply  understanding  end-users’ 
requirements  for  GMTI  support.  Given  the  complex,  multidimensional  nature  of  GMTI  data  collection,  it 
is  difficult  for  non-GMTI  experts  in  need  of  GMTI  support  to  clearly  articulate  their  tasking  requirements. 
Thus,  there  is  often  a  divide  between  such  end-users  in  need  of  GMTI  support  and  collection  managers 
who  task  GMTI  assets. 

One  approach  to  bridge  this  divide  would  be  to  require  GMTI  requesters  to  articulate  specific  GMTI 
collection  parameters,  such  as  the  required  area  revisit  rate,  needed  to  accomplish  their  operational 
objective.  This  approach  is  problematic  for  a  variety  of  reasons.  For  one,  end  users  often  do  not  possess 
sufficient  expertise  to  understand  the  relationship  between  GMTI  collection  parameters  and  operational 
objectives.  For  another,  such  collection  parameters  may  be  highly  dependent  upon  a  variety  of  contextual 
factors,  such  as  the  traffic  density  of  the  target  environment  and  the  specific  GMTI  platform  employed. 
Collection  managers  and  GMTI  platform  operators  are  still  left  with  an  insufficient  understanding  of  the 
end-user’s  objective  that  would  enable  them  to  tailor  platform  tasking  and  operation  to  varying 
circumstances.  As  one  platform  operator  lamented,  “my  hands  were  tied  to  a  revisit  rate  and  I  didn’t 
understand  how  the  data  I  collected  would  be  used.” 

We  instead  propose  an  approach  that  aims  to  elicit  the  mission  (i.e.,  operational  objective)  the  end-user 
intends  to  accomplish  with  GMTI  support.  Our  approach  then  aims  to  elicit  each  of  the  elements  a 
collection  manager  or  platform  operator  would  need  to  effectively  task  a  GMTI  asset  against  a  support 
request.  Moreover,  we  aim  to  also  provide  a  modeling  methodology  for  moving  from  the  mission  and 
other  elements  of  the  support  request  to  the  specification  of  collection  parameters  that  account  for  the 
operational  environment  and  the  specific  GMTI  platform  to  be  employed  (this  is  the  purview  of  our 
GMTI  Planning  Tool  described  in  section  3.2). 

To  better  understand  the  needs  of  end-users  (the  “requesters”),  we  first  examined  requests  for  GMTI 
support  that  had  been  previously  made  and  identified  which  intelligence  problems  and  objectives  GMTI 
collections  were  being  used  to  support.  We  then  derived  a  set  of  standard  GMTI  mission  types  (defined 
in  Figure  1)  that  include  things  such  as  “Track  high  value  targets  or  individuals”,  “Monitor  a  border, 
facility,  or  other  area  of  interest”,  and  “Identify  patterns  of  life  in  an  area  of  interest”.  We  also  developed 
an  associated  set  of  GMTI-specific  Essential  Elements  of  Information  (EEIs)  that  capture  the  types  of 
activity  or  patterns  of  target  behavior  that  are  of  interest  to  the  requester.  EEIs  include  things  such  as 
“identify  traffic  patterns”,  “identify  milling  activity”,  or  “identify  activity  along  established  routes”. 


Mission  Types: 

1 .  Track  high  value  targets:  A  mission  to  track  high  value  targets  for  possible  engagement.  An 
example  is  tracking  vehicles  suspected  of  planting  IEDs  along  a  road. 

2.  Monitor  a  border  or  facility:  A  mission  to  monitor  a  border  or  facility  for  activity.  An  example  is 
monitoring  a  border  for  vehicle  crossings,  or  monitoring  a  facility  for  vehicles  that  come  within  a 
certain  distance  of  it. 

3.  Perform  force  protection/convoy  watch:  A  mission  to  monitor  for  targets  that  come  within  a  certain 
distance  of  a  troop  or  convoy  location. 

4.  Maintain  situation  awareness  in  a  region:  A  mission  to  monitor  target  activity  in  a  region.  An 
example  is  monitoring  an  area  for  any  vehicle  movement. 

5.  Identify  patterns  of  activity  in  a  region:  A  mission  to  identify  common  patterns  of  target  movement 
in  a  region.  An  example  would  be  monitoring  a  road  to  establish  traffic  patterns,  or  monitoring  a 
facility  to  establish  when  vehicles  typically  come  and  go. 

Essential  Elements  of  Information  (EEIs): 

1 .  Baseline  Movement:  Determine  normal  activity  in  an  area  of  interest,  such  as  traffic  patterns  and 
human/animal  movements,  to  detect  activity  outside  of  normal  patterns. 

2.  Traffic  Patterns:  Detect  movement  along  communications  routes  such  as  roads  and  trails  which  have 
been  previously  identified  via  intelligence  analysis  or  global  databases.  Establish  basic  target 
information  including  target  velocity  estimates  and  number  of  targets. 

3.  Activity  on  Established  Routes:  Detect  movement  along  communications  routes  such  as  roads  and 
trails  which  have  been  previously  identified.  Establish  basic  target  information  including  target 
velocity  estimates  and  number  of  targets. 

4.  Activity  on  Non-Traditional  Routes:  Detect  the  appearance  of  activity  in  areas  where  no  established 
routes  have  previously  been  detected  or  where  no  data  was  collected  previously. 

5.  Post-Incident  Backtracking  (Forensic):  Collect  data  at  a  level  sufficient  to  support  determination  of 
the  origination  of  tracks  that  may  have  been  involved  in  an  event  of  interest  (e.g.,  an  IED 
emplacement). 

6.  Non-Incident  Backtracking  (Forensic):  Collect  data  at  a  level  sufficient  to  support  determination  of 
the  origination  of  tracks  that  may  have  been  involved  in  an  event  of  interest  (e.g.,  an  IED 
emplacement). 

7.  Milling  Activity:  Identify  concentrated  target  movement  in  an  area  of  interest.  Data  may  not  provide 
sufficient  resolution  to  separate  individual  targets. 

Figure  1:  Proposed  GMTI  mission  types  and  EEIs. 

Having  established  a  set  of  GMTI  mission  types  and  EEIs,  we  next  examined  other  key  elements  that 
collection  managers  or  platform  operators  would  need  to  be  aware  of  to  effectively  task  a  request.  These 
elements  are  used  to  answer  questions  that  include:  “what  do  I  look  for?”,  “where  do  I  look?”,  and  “when 
do  I  look  there?”  (Figure  2).  This  gives  rise  to  a  need  to  elicit  targets  of  interest  (e.g.,  vehicles, 
watercraft),  a  region  of  interest,  and  the  timing  requirements  for  the  request.  We  delve  into  each  of  these 
elements  in  more  detail  in  Section  3.1  in  the  context  of  a  software  system  for  eliciting  a  request.  In  the 
next  section,  we  discuss  how  key  aspects  of  these  elements  are  formalized  and  used  in  MTIIRS  to 
describe  required  GMTI  data  fidelity. 
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Figure  2:  Collection  manager  tasking  questions. 


2.2.  The  Moving  Target  Indicator  Interpretability  Rating  Scale  (MTIIRS) 


MTIIRS  provides  a  common  framework  for  defining  both  the  fidelity  required  to  support  GMTI  requests 
and  for  assessing  the  fidelity  of  previously  collected  GMTI  data  [1].  GMTI  data  fidelity  can  be  defined  as 
the  relative  ability  to  uniquely  distinguish  individual  targets  over  a  period  of  time.  Increased  data  fidelity 
results  in  the  ability  to  track  individual  targets,  while  low  fidelity  data  provides  a  sense  of  motion  or 
activity  across  the  scene  (e.g.,  to  identify  traffic  patterns)  but  may  not  allow  a  tracker  or  analyst  to 
associate  individual  entities  from  scan  to  scan  [2].  Both  high  and  low  fidelity  GMTI  data  can  be  of 
operational  utility,  and  the  ability  to  properly  quantify  the  GMTI  data  quality  needed  for  a  specific 
mission,  and  to  determine  whether  a  particular  sensor  can  provide  data  of  this  quality,  will  allow  for  more 
efficient  use  of  limited  sensor  resources.  Furthermore,  when  associated  with  archived  GMTI  data,  this 
information  will  assist  unanticipated  (future)  users  in  identifying  data  which  can  be  used  to  satisfy  their 
unique  needs. 


The  impetus  for  such  a  scale  was  inspired  by  the  National  Imagery  Interpretability  Rating  Scale  (NIIRS). 
Specifying  collections  using  a  NIIRS  scale  number  ensures  that  the  right  image  quality  is  obtained  for  the 
intended  mission  requirement;  likewise,  the  NIIRS  scale  has  aided  in  the  efficient  allocation  of  imagery 
collection  resources  by  providing  a  common  language  to  describe  image  quality.  Applying  this  approach 
to  radar-based  MTI  data  has  been  problematic  due  to  the  multi-dimensional  nature  of  GMTI  collection 
parameters.  MTIIRS  specifies  quality  levels  of  MTI  data  collection.  The  intent  of  creating  this  scale  is  to 
provide  a  common  set  of  terms  and  conditions  that  allows  for  better  tasking  of  GMTI  platforms  and  an 
enhanced  understanding  of  the  usability  of  individual  data  sets  to  support  specific  mission  needs. 
Standardizing  terms  and  conditions  will  also  pave  the  way  for  enabling  collaborative  GMTI  mission 
planning  in  coalition  C2  environments. 


Historically  and  currently,  GMTI  data  collection  has  instead  been  quantified  using  a  metric  (the  “Hegyi” 
unit)  based  on  the  size  of  the  collection  area  scanned  per  hour  [2].  This  metric  is  insufficient  for  a 
number  of  reasons.  For  one,  it  does  not  account  for  how  the  data  will  be  used,  so  it  could  encourage  and 
reward  arbitrary  collection  planning  whose  only  goal  is  to  collect  large  volumes  of  data  with  no  regard  for 
the  operational  utility  of  the  data.  For  another,  it  was  developed  without  a  careful  analysis  of  the  uses  for 
such  a  metric  or  input  from  the  GMTI  community,  and  it  does  not  allow  for  discrimination  among  the 
quality  of  different  GMTI  collections.  Moreover,  due  to  the  nature  of  GMTI  data,  high  rates  of  coverage 
will  often  result  in  data  which  is  of  no  operational  utility  due  to  an  insufficiently  low  update  rate. 
Alternatively,  one  could  quantify  the  data  based  on  the  number  of  GMTI  reports  collected.  However,  such 
a  metric  would  also  be  problematic  since  a  high  density  of  GMTI  reports  can  again  render  the  data 
unusable  as  individual  targets  cannot  be  resolved  across  time. 

Facilitated  by  the  utility  metrics  working  group  at  the  Surface/GMTI  community  of  practice,  we 
collaborated  with  the  GMTI  collection  and  exploitation  community  to  develop  MTIIRS.  There  are  as 
many  approaches  to  the  problem  of  quantifying  GMTI  radar  data  quality  as  there  are  disciplines  within 
radar  engineering,  and  these  different  approaches  were  examined  at  length.  The  working  group  ultimately 
agreed  that  a  useful  description  of  levels  of  data  fidelity  must  be  based  upon  the  usability  of  the  GMTI 
data  and  be  understood  by  GMTI  data  exploiters  and  collection  managers  who  may  not  have  a  high  level 
of  technical  expertise  in  the  physics  of  GMTI  radar.  We  have  chosen  to  represent  these  data  quality 
levels  on  a  linear  scale,  despite  the  multi-dimensional  nature  of  the  problem,  because  our  goal  is  to 
provide  a  useful  and  easy-to-understand  metric  that  will  assist  the  community  in  both  planning  and 
exploitation  and  be  straightforward  enough  to  be  universally  adopted. 

Our  first  goal  was  to  standardize  a  set  of  GMTI  mission  types  and  EEIs.  This  enables  the  collection 
manager  or  platform  operator  to  take  into  consideration  the  intended  use  of  the  data.  The  mission  type 
gives  rise  to  the  required  surveillance  capability  (i.e.,  a  general  understanding  of  the  moving  target 
environment  [movement]  vice  tracking  specific  targets  [tracking]).  Other  key  elements  include  the  targets 
of  interest  (vehicles  vice  dismounts)  and  their  associated  radar  cross  section  (RCS)  and  maneuverability. 
Finally,  the  characteristics  of  the  region  of  interest  must  be  taken  into  consideration  (i.e.,  the  overall  target 
density  and  terrain  characteristics).  Ultimately,  sensor  operation  during  the  data  collection  must  account 
for  more  specific  factors  associated  with  the  target  collection  environment  (e.g.,  relative  target 
speed/density  for  the  time  of  day  of  the  collection;  target  maneuverability  consistent  with  the  indigenous 
road  network;  obscuration,  etc.)  [3]. 

The  triad  of  required  surveillance  capability,  target  types  of  interest,  and  environmental  characteristics 
gives  rise  to  the  required  MTIIRS  data  fidelity  level.  The  six  draft  MTIIRS  levels  are  shown  in  Figure  3 
and  were  developed  to  quantize  the  fidelity  of  localizing  targets  across  a  broad  set  of  target  and 
environmental  factors.  In  the  next  section,  we  step  through  the  formulation  of  a  GMTI  support  request 
using  the  PRISM  Input  Tool  and  detail  the  formulation  of  an  MTIIRS  level  from  the  request  elements. 
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Figure  3:  Draft  MTIIRS  levels. 


3.  Tools  for  Improved  GMTI  Asset  Requesting  and  Tasking 

3.1.  The  “PRISM  Input  Tool”  for  requesting  GMTI  support 

The  “PRISM  Input  Tool”  is  a  web-based  software  tool  that  provides  an  intuitive,  wizard-like  interface  to 
create  requests  for  GMTI  support  [4].  Our  aim  was  to  make  the  tool  usable  by  non-GMTI  and  GMTI 
experts  alike.  After  first  specifying  a  point-of-contact  (i.e.,  the  supported  unit  in  need  of  the  GMTI  data), 
the  user  selects  a  GMTI-specific  collection  objective  (i.e.,  the  mission  type)  and  an  associated  set  of  EEIs 
(Figure  4).  Figure  1  provides  the  current  set  of  collection  objectives  and  EEIs  used  in  the  tool.  The 
collection  objective  gives  rise  to  the  first  aspect  of  an  MTIIRS  level  -  the  required  surveillance  capability 
(one  of  “general  movement”  or  “tracking”).  EEIs  enabled  for  selection  are  dependent  upon  the 
surveillance  capability  of  the  collection  objective.  In  the  case  of  the  example  in  Figure  4,  EEIs  that 
require  tracking  are  not  enabled  since  the  overall  collection  objective  is  to  “Identify  patterns  of  life  in  a 
region”,  which  corresponds  to  a  “general  movement”  surveillance  capability. 
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Figure  4:  The  PRISM  Input  Tool  -  Specifying  collection  objective  and  EEls. 


The  user  next  indicates  the  specific  types  of  targets  that  the  requester  is  interested  in  monitoring  or 
tracking.  The  tool  currently  contains  the  following  breakdown  of  target  types: 

•  Vehicles:  small  vehicles  (e.g.,  cars),  large  vehicles  (e.g.,  trucks),  vehicle  convoys 

•  Low-flying  aircraft 

•  Watercraft:  small  craft  (e.g.,  pleasure  craft),  large  craft  (e.g.,  commercial  ships  in  excess  of  300 
tons) 

•  Dismounts  (people  and  animals) 


In  formulating  an  MTIIRS  level,  the  tool  considers  the  target  type  selected  with  the  smallest  nominal 
radar  cross  section.  For  the  purposes  of  MTIIRS,  the  radar  cross  section  is  categorized  as  either  large 
(e.g.,  vehicle-sized)  or  small  (e.g.,  dismount-sized). 

Next,  the  user  specifies  the  geographic  area  of  interest  and  any  specific  features  in  the  region  (e.g.,  a  road, 
location,  etc.)  that  are  of  particular  interest  to  the  requester.  For  example,  a  requester  may  be  primarily 
interested  in  monitoring  activity  at  a  boathouse  (the  “feature”)  in  a  region  that  encompasses  an  entire  lake. 
Currently,  the  user  must  also  specify  the  environmental  properties  of  the  region  of  interest,  including  the 
traffic  density  (one  of  “rural”  or  “suburban”).  The  traffic  density  is  the  final  aspect  of  the  request  used  in 
the  MTIIRS  formulation.  In  the  future,  the  time-dependent  traffic  density  of  a  region  should  be  available 
in  databases  that  maintain  dynamic  aspects  of  a  target  environment  gathered  from  previous  data 
collections. 


Finally,  the  user  specifies  the  timing  requirements  for  the  request.  Requests  may  be  “one-time”  in  nature, 
where  the  collection  is  performed  once  in  support  of  a  particular  operation  (e.g.,  force  protection),  or  they 
may  be  “recurring”  in  nature,  where  the  requester  needs  to  monitor  a  region  for  a  period  of  days  or  weeks 
to  establish  patterns  of  activity.  Figure  5  shows  the  final  screen  in  the  tool  that  provides  a  formatted 


paragraph  summarizing  the  elements  of  the  request.  The  ultimate  goal  is  to  integrate  the  PRISM  Input 
Tool  with  the  PRISM  system  of  record,  a  system  for  managing  ISR  collection  requirements  across  a 
variety  of  sensing  modalities  [5]. 


Figure  5:  The  PRISM  Input  Tool  -  A  formatted  summary  of  a  GMTI  support  request. 

3.2.  The  GMTI  Planning  Tool  for  developing  GMTI  collection  plans 

Given  a  set  of  requests  for  GMTI  support  at  varying  levels  of  MTIIRS  fidelity,  it  is  now  the  job  of  the 
collection  manager  to  effectively  task  GMTI  platforms  against  those  requests.  This  is  a  complex  problem 
that  requires  the  use  of  sophisticated  models  of  sensor  collection  capability  to  relate  support  requests  to 
GMTI  collection  parameters  needed  to  satisfy  the  requests  and  achieve  the  required  level  of  fidelity. 

In  order  to  properly  relate  requests  to  sensor  tasking,  it  is  necessary  to  first  develop  a  rigorous  basis  for 
quantifying  collection  requirements.  GMTI  collection  characteristics  can  largely  be  described  as  a 
combination  of  three  interrelated  performance  parameters:  persistence,  target  state  estimation,  and 
tracking  fidelity.  By  persistence  we  mean  the  frequency  with  which  an  area  of  interest  must  be 
interrogated  or  sampled  and  the  time  duration  over  which  this  sampling  needs  to  occur.  This  could  be  a 
sensor  revisit  as  often  as  every  few  seconds  for  high  value  target  tracking,  or  scans  as  infrequently  as  once 
every  few  days  for  long  term  pattern  of  life  analysis.  Target  state  estimation  is  the  ability  to  judge  a 
target’s  true  position  and  velocity,  and  is  a  function  of  sensor  accuracy,  collection  diversity,  and  update 
rate,  among  other  factors. 


Tracking  fidelity  is  computationally  the  most  difficult  of  these  three  collection  performance  parameters  to 
estimate.  The  GMTI  target  tracking  performance  model  we  have  selected  was  first  proposed  by  Mori, 
Chang,  Chong  and  Dunn:  Probability  of  Correct  Association  (Pea)  [6].  Research  efforts  at  the  MITRE 
Corporation  have  extended  the  basic  Pea  concept  outlined  in  this  foundational  paper  to  account  for  the 
particular  characteristics  of  target  tracking  based  on  GMTI  radar  data.  We  have  used  the  results  of  that 
research  in  our  development  of  the  GMTI  planning  tool.  Pea  is  defined  as  the  relative  probability  of 
correctly  associating  a  target  return  to  its  associated  track  between  successive  GMTI  updates.  Pea  is 
intended  to  account  for  the  uncertainty  in  identifying  a  specific  target  in  successive  sensor  scans  for  a 
given  set  of  independent  variables,  including  average  target  speed,  relative  maneuverability,  traffic 
density,  and  sensor  error.  The  required  minimum  Pea  value  can  be  associated  with  differing  mission 
requirements,  e.g.,  large  area  situational  awareness  (SA);  small  area  SA;  force  protection/overwatch; 
tracking  of  specific  targets,  etc. 

In  summary,  our  modeling  methodology  derives  a  Pea  value  required  to  meet  the  collection  objective  and 
EEIs  of  a  request,  and  this  Pea  value,  in  combination  with  the  expected  speed  and  maneuverability  of  the 
target  types  of  interest  and  the  traffic  density  of  the  region  of  interest,  is  used  to  derive  a  maximum  revisit 
time  for  a  specific  GMTI  sensor  needed  to  satisfy  the  requirements  of  the  request.  The  maximum  revisit 
time  and  size  of  the  area  of  interest  govern  the  utilization  of  a  specific  GMTI  sensor  (i.e.,  the  amount  of 
its  available  timeline  that  will  be  consumed  performing  the  collection). 

This  modeling  methodology  underpins  our  GMTI  Planning  Tool  (Figure  6),  which,  given  a  set  of  requests 
for  GMTI  support  and  a  set  of  available  GMTI  platforms,  derives  the  anticipated  performance  of  each 
platform  against  each  request.  The  result  is  a  platform-to-request  performance  matrix  that  enables  the 
collection  manager  to  see  at-a-glance  the  expected  performance  of  each  GMTI  platform  against  each 
GMTI  request  (Figure  7).  The  matrix  concept  was  developed  using  principles  of  structure  mapping  for 
decision  support  design,  which  entails  mapping  the  structure  of  the  planning  problem  to  the  visual 
elements  in  the  display  [7].  The  cells  in  the  performance  matrix  show  the  expected  area  coverage,  the 
quality  of  the  coverage  given  the  fidelity  requirements  of  the  request  (color-coded  green,  yellow,  or  red), 
and  the  utilization  of  the  platform’s  sensor. 
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re  6:  GMTI  Planning  Tool  -  Overview. 


Figu 


In  the  example  in  Figure  7,  the  first  column  in  the  matrix  shows  the  performance  of  two  sample  GMTI 
platforms  against  a  sample  collection  request  in  a  140  km2  region.  In  this  notional  example,  Sample 
Platform  1  is  able  to  cover  the  entire  area  with  sufficient  quality  while  utilizing  12%  of  its  available 
timeline,  while  Sample  Platform  2  is  able  to  cover  half  the  area  with  mediocre  quality  while  utilizing  its 
entire  available  timeline. 
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Figure  7:  GMT  Planning  Tool  -  Platform  performance  matrix. 


The  collection  manager  clicks  cells  in  the  performance  matrix  to  construct  an  assignment  of  platforms  to 
requests.  The  tool  then  updates  the  overall  utilization  of  each  platform  and  the  overall  performance 
against  each  request  based  on  the  assignment  of  platforms  to  requests  (Figure  8).  Armed  with  this  initial 
assignment  of  platforms  to  requests,  the  collection  manager  now  has  a  rough  cut  at  the  collection  deck  for 
each  platform.  The  collection  manager  may  then  use  the  interactive  map  to  position  platform  orbits  and 
evaluate  terrain  screening  (Figure  9).  As  the  collection  manager  manipulates  a  platform  orbit,  the  tool 
updates  the  performance  of  the  platform  against  each  assigned  request.  Thus,  the  collection  manager  may 
perform  a  more  detailed  assessment  of  platform-request  performance  given  an  orbit  and  the  actual  terrain 
in  the  area  of  interest.  The  end  result  is  a  collection  deck,  and  possibly  an  orbit,  for  each  platform. 


Figure  8:  GMTI  Planning  Tool  -  Platform  performance  matrix  after  assigning  platforms. 
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Figure  9:  GMTI  Planning  Tool  -  Orbit  analysis. 


4.  Conclusion  and  Next  Steps 

We  have  demonstrated  an  integrated  approach  that  aims  to  standardize  the  process  of  requesting  GMTI 
support  and  tasking  GMTI  platforms  while  overcoming  the  complexities  of  GMTI  data  collection.  We 
presented  a  methodology  for  requesting  GMTI  support  based  on  operational  needs,  a  new  MTIIRS  metric 
for  assessing  required  GMTI  data  fidelity,  and  a  planning  tool  to  relate  GMTI  requests  to  platform 
performance  and  plan  effective  GMTI  collections.  Such  a  holistic  approach  to  GMTI  planning  can  go  a 
long  way  toward  bridging  the  divide  between  end-users  in  need  of  GMTI  support  and  collection  managers 


and  platform  operators  who  provide  such  support.  Moreover,  the  adoption  of  a  standardized  set  of  GMTI 
mission  types  and  planning  methodology  can  also  help  establish  common  ground  and  enable  improved 
inter-service  and  coalition  GMTI  support  and  planning.  We  intend  to  next  investigate  the  application  of 
this  methodology  to  other  sensing  modalities  (e.g.,  full  motion  video,  signals  intelligence).  In  the  GMTI 
domain,  we  also  intend  to  extend  this  methodology  to  comprehend  cross  cue  requests  that  require  the 
coordination  of  GMTI  and  other  sensor  types. 
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Introduction  -  What  is  GMTI? 


■  GMTI  =  Ground  Moving  Target 
Indicator 

An  I  NT  type  that  detects  and  tracks 
moving  surface  objects  in  an  area  of 
interest 

Detections  can  be  associated  to  form 
tracks,  or  used  for  situational  awareness 

Traditionally  radar-based,  but  can  be 
from  other  sources  such  as  video  and 
SIGINT 

■  Typical  uses  of  GMTI 

Discover  and  characterize  lines  of 
communication 


Monitor  borders 


Track  high  value  targets 
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GMTI  Planning  Challenges 


■  GMTI  data  collection  is  complex  and  multi-dimensional, 
involving  detection  across  time  and  space 

■  GMTI  planning  today  is  based  on  implicit  assumptions  about 
the  effectiveness  of  GMTI  sensing  strategies  in  meeting 
operational  objectives. 

■  Collaboration  and  planning  suffers  from  inconsistencies  in 
these  assumptions  between  humans  and  machines,  as  well  as 
between  humans  in  different  echelons,  locations,  and 
organizations.  [Hence  lots  of  chat.] 

■  Standardized  mission  types  and  model-driven  mission  planning 
tools  are  needed  to  provide  potential  sensing  strategies 
spanning  multiple  GMTI  sensors/platforms  that  satisfy  end-user 
operational  objectives. 
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Mission-Based  GMTI  Planning  Process 


GMTI  Requesters 


/ - \ 


GMTI  Planners 


Current 

Process 


“I  need  a  JSTARS  with  a  10 
second  revisit  rate.”  Lack 
tools  to  structure  requests  in 
mission-centric  terms. 


“Hands  tied”  to  requested  revisit 
rates.  Requests  often  lack  needed 
information. 

Lack  systems  to  evaluate  mission 
satisfaction  and  plan  multi-platform 
collects. 


Improved 

Process 


Mission:  “I  need  to  identify 
traffic  patterns  along  a  road.” 


Mission-Based 
GMTI  Request 


MTIIRS  Level 


PRISM  Input  Tool© 


Provide  decision  support  tools  to 
evaluate  tasking  requirements  and  plan 
GMTI  collections  based  on  mission 
needs  and  area  characteristics. 


GMTI  Planning  Tool© 
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GMTI  Mission  Types  and  Essential 
Elements  of  Information  (EEls) 


■  Mission  Types: 

-  Track  high  value  targets 

Monitor  a  border,  facility,  or  other  area  of  interest 
Perform  force  protection  or  convoy  over-watch 

-  Maintain  situation  awareness  in  a  region 

-  Identify  patterns  of  activity  in  a  region 


■  EEls 

-  Characterize  baseline  movement 

-  Establish  traffic  patterns 

Identify  activity  on  established  routes 
Identify  activity  on  non-traditional  routes 
Perform  incident  backtracking  (forensics) 
Identify  enemy  reactions  to  friendly  actions 

-  Identify  milling  activity 
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fill 


The  Moving  Target  Indicator 
Interpretability  Rating  Scale  (MTIIRS) 


■  Previous  efforts  to  define  GMTI  fidelity  based  on  the  analogy  to 
imagery:  National  Imagery  Intelligence  Interpretability  Rating 
Scale  (NIIRS) 

-  Imperfect  analogy:  GMTI  data  is  not  imagery 

-  GMTI  data  fidelity  is  the  degree  to  which  targets  are 
unambiguously  distinguished 

■  Current  approach:  “GMTI  Units”  based  on  area  scanned  per 
hour  is  insufficient  as  it  does  not  consider  update  rate 

■  MTIIRS  Approach: 

Characterize  required  GMTI  data  fidelity  given  mission  requirements 

-  Enable  collection  planners  to  bin  requests  by  difficulty 

-  Characterize  fidelity  of  previously  collected  GMTI  data 

■  MTIIRS  is  currently  is  linear  scale  comprised  of  6  levels  in 
increasing  order  of  fidelity 

■  MTIIRS  levels  are  derived  from  the  triad  of  mission  type,  target 
types  of  interest,  and  area  characteristics 


MITRE 


©2011  The  MITRE  Corporation.  All  rights  reserved 


7 


Current  MTIIRS  Levels 


MTIIRS  Level 


Surveillance 

Capability  Environment 


General 

Movement 


Rural  or 
Suburban 


Vehicular 


General  Rural  or  Vehicular  & 

2  Movement  Suburban  Congregations 

3  Tracking  Rural  Vehicles 

4  Tracking  Suburban  Vehicles 

5  Tracking  Rural  Dismounts 

S  Tracking  Suburban  Dismounts 


MTIIRS  Levels 

Rural 

Suburban 

Rural 

Suburban 

Vehicles 

Vehicles 

Dismounts 

Dismounts 

Wide  Area  Surveillance 

/  Situation  Awareness 

1 

1 

2 

2 

Tracking 

3 

4 

5 

6 
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PRISM  Input  Tool® 

Structuring  GMTI  Requests 


■  Goal:  Develop  a  software  tool  to: 

Assist  in  requesting  GMTI  support  in  mission-centric  terms 

■  Old  Way:  “I  need  a  JSTARS  with  a  30  second  revisit  rate” 

■  New  Way:  “I  need  to  identify  traffic  patterns  along  a  road” 

-  Add  structure  to  the  GMTI  request  process 

-  Be  “Turbo  Tax”  easy-to-use 

-  Compute  an  MTIIRS  level  based  on  request 
Export  requests  as  formatted  text  and  XML  to  PRISM 


■  Needs  Addressed: 

GMTI  requests  are  currently  poorly  structured  and  not  reproducible 

-  GMTI  is  not  a  well  understood  I  NT  type  by  end-users 

-  Structuring  requests  will: 

■  Standardize  the  process  and  avoid  confusion 

■  Help  requesters  understand  GMTI  a 

■  Help  planners  better  manage  and  utilize  GMTI  assets 
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PIT:  Specifying  Mission  Type  and  EEls 


Help 


Request  name:  The  name  to  use  for  the  request.  The  request 
will  be  saved  for  later  retrieval  using  this  name. 

Theater:  The  theater  the  request  takes  place  in  (OEF  or  OIF). 


Collection  Objective:  The  type  of  objective/mission  the  request 
will  support.  Collection  objectives  include: 


•  T rack  high  value  targets:  A  mission  to  track  high  value 
targets  for  possible  engagement.  An  example  is  tracking 
vehicles  suspected  of  planting  lEDs  along  a  road. 

•  Monitor  a  border  or  facility:  A  mission  to  monitor  a  border 
or  facility  for  activity.  An  example  is  monitoring  a  border  for 
vehicle  crossings,  or  monitoring  a  facility  for  vehicles  that 
come  within  a  certain  distance  of  it. 

•  Perform  force  protection/convoy  watch:  A  mission  to 
monitor  for  targets  that  come  within  a  certain  distance  of  a 
troop  or  convoy  location. 

«  Maintain  situation  awareness  in  a  region:  A  mission  to 
monitor  target  activity  in  a  region.  An  example  is 
monitoring  an  area  for  any  vehicle  movement. 

•  Identify  patterns  of  activity  in  a  region:  A  mission  to  identify 
common  patterns  of  target  movement  in  a  region.  An 
example  would  be  monitoring  a  road  to  establish  traffic 
patterns,  or  monitoring  a  facility  to  establish  when  vehicles 

Hi  ,r-,\n  --hill  ■  nnmn  ^i^ri  ~h  n,  /K 


EEls  enabled  for 
selection  are  specific  to 
the  mission  type 


Context- 
sensitive  help 
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MTIIRS  Calculation 
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PIT:  Request  Summary 


Formatted 
summary 
paragraph 
of  request 


“Save”  when  inputs 
are  complete 


“Export”  provides  a 
text  file  that 
can  be  copied  to 
PRISM 
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GMTI  Planning  Tool® 

GMTI  Platform  Planning  and  Optimization 


■  Goal:  Develop  a  decision  support  capability  to: 

Provide  a  structure  to  allow  a  non-expert  to  determine  radar  tasking 
requirements  based  on  mission  needs,  target  type  and  area 
conditions 

Evaluate  which  and  how  many  GMTI  platforms  are  required  to 
satisfy  requests 

Determine  placement  and  orbit  of  platforms  to  maximize  collection 
effectiveness 

Predict  and  visualize  performance  based  on  platform  placement  and 
orbits 


■  Needs  Addressed: 

Current  systems  for  tasking  GMTI  collections  do  not  provide 
adequate  feed  back  as  to  whether  they  satisfy  mission  needs 

No  systems  exist  to  plan  multi-platform  GMTI  missions 

Improve  GMTI  platform  utilization  (reduce/eliminate  incorrect 
tasking) 
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GPT:  Overall  Tool  Layout 


The  platforms 
browser 
enables 
planners  to 
add,  edit,  and 
remove  GMTI 
platforms. 


The  collections 
browser  allows 
planners  to 
add,  edit,  and 
remove  GMTI 
collections. 


The  interactive  map  shows  areas  requiring  GMTI  coverage 


The  analysis  area  contains  an  interactive  assignment 
matrix  that  shows  the  expected  performance  of  each 
platform  against  each  collection. 


MITRE 


©2011  The  MITRE  Corporation.  All  rights  reserved 


14 


Summary  and  Future  Directions 


■  Our  aim  is  to  standardize  the  process  of  requesting  GMTI 
support  and  tasking  GMTI  platforms  with  a  mission-based 
framework 

■  We  demonstrated  a  framework  for  requesting  support  based  on 
mission  needs,  a  new  MTIIRS  metric  to  assess  required  fidelity, 
and  a  planning  tool  to  relate  requests  to  platform  tasking 

■  We  intend  to  next  investigate  extending  this  methodology  by 
understanding  how  GMTI  can  be  combined  with  other  INT  types 

■  We  also  intend  to  validate  our  utility  models  using  theater  GMTI 
data  collects 


Mission-Based 
GMTI  Request 


MTIIRS  Level 


Sensor  Tasking 
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